In addition to the traditional best-effort service provided by the Internet Protocol (IP) to traffic carried by it, there is a need for enhanced and controllable Quality of Service (QoS) for traffic of some kinds of applications. For example, real-time applications may need to obtain at least a minimum amount of bandwidth exclusively for their traffic to perform properly. QoS requirements may also include bounds on delay, jitter, or similar. The need for QoS has been addressed by the IETF through the definition of two QoS architectures: The Integrated Services (IntServ) and the Differentiated Services (DiffServ/DS) architecture.
The IntServ architecture ([RFC 1633], for all references see list “References” below) reserves QoS-related resources for individual data flows, in all compliant routers along the paths of the flows through an IP network. This reservation is typically performed by means of the Resource Reservation Protocol (RSVP; [RFC 2205]), which enables applications to explicitly request specific services, provide traffic- and service-related parameters, and get feedback whether or not a reservation has been established. IntServ services include the Controlled-Load service (CL; [RFC 2211]) and the Guaranteed service (GS; [RFC 2212]). Whereas the per-flow reservation is application-friendly, it limits the scaling properties of IntServ/RSVP in large networks (e.g., WANS, or the Internet core/backbone).
The DiffServ architecture ([RFC 2475]) provides QoS to aggregates of data flows instead of individual flows, with such aggregates identified by the DS codepoint (DSCP) marking in an IP packet header ([RFC 2474], [RFC 3260]). Moreover, it operates on network areas consistently configured to provide DiffServ-style QoS (so-called DS domains), pushing most of the complex traffic classification and management tasks to the edges of a DS domain, where these tasks are performed according to Service Level Agreements (SLAs) with an adjacent domain. Whereas this approach provides scaling properties suitable for large networks, it lacks the quantifiable per-flow QoS of IntServ/RSVP and does originally not provide QoS negotiation and feedback mechanisms. An approach to dynamic management of a DS domain, including communication with local hosts, and potentially with adjacent domains, is a so-called Bandwidth Broker (BB; [RFC 2638]), but no communication mechanism has been standardized for this approach.
As IntServ and DiffServ are somewhat complementary, a proper combination of both seems to be the most promising approach to an overall QoS architecture within the Internet ([RFC 2998]). This architecture uses IntServ/RSVP at the edges of the network, to provide quantifiable per-flow QoS negotiation and feedback to applications, but uses DiffServ mechanisms in the network core to provide scalability. Another concept for interoperation of IntServ and DiffServ is RSVP Aggregation ([RFC 3175]), which uses in the network core aggregate RSVP reservations to which multiple end-to-end (E2E) reservations are mapped. Moreover, packets within aggregate reservations are identified by means of a DSCP marking, which is selected by the deaggregating router and reported to the aggregating router via an RSVP DCLASS object ([RFC 2996]).
Both IntServ/RSVP and DiffServ are conceptually designed for large-scale, sophisticated networks depending on layer 3 (L3) router functionality (RSVP routers, DiffServ border routers, etc.). Especially, RSVP reservations are in principle set up for the path to a downstream next-hop router. On the other hand, LANs typically mainly operate on layer 2 (L2) functionality (L2 switches/bridges, etc.). For example, a LAN may consist of several hosts connected by a switched Ethernet environment, with only a few routers or even one router being responsible for connection of the LAN to other networks or the Internet. To enable fine-grain RSVP operation in such environments, the concept of a Subnet Bandwidth Manager (SBM) has been introduced ([RFC 2814]).
Finally, a real deployment of QoS within the network(s) of a company needing some QoS support to enable certain applications must consider both the features and the costs of the equipment necessary to achieve a desired QoS level, as well as the features of the existing equipment. IntServ/RSVP is typically only supported by medium- to high-class routers, and many switches do not provide SBM support. On the other hand, many routers and switches provide DiffServ support, making it very tempting to use DiffServ for QoS in a less sophisticated environment. In the latter case, the non-standardized communication mechanism between hosts and DiffServ management entities must be defined to enable applications to issue QoS request and get feedback, and this mechanism must interoperate with the existing network equipment. Points of implementation of this mechanism can typically only be the hosts and the management entities, both of which can process company-specific network protocol software, whereas one would normally not be able to adapt the firmware and thus the behavior of intermediate network equipment.
[RFC 2638] describes the BB concept for management of a DS domain, with the BB functionality being quite similar to the functionality of the QoS Manager proposed by the invention. Both entities must perform management and configuration of the resources of the domain they are responsible for. According to [RFC 2638], a BB may configure the controlled network elements by means of a derivate of RSVP, SNMP, or a vendor-specific protocol. The QoS Manager of the invention is intended to use any suitable remote configuration interface of the network equipment it controls (e.g., SNMP, Telnet, or SSH). However, [RFC 2638] does not detail the communication mechanism needed for application-centric reservation setup and feedback. It simply states that a reservation request may be issued manually, or by means of some network administration or resource negotiation protocol. The invention fills this gap by using RSVP Shadowing as its communication mechanism.
[RFC 2638] further states that BBs of adjacent domains may communicate with each other for dynamic resource management, again without detailing the communication mechanism. In some embodiments of the invention, said communication is also performed via RSVP Shadowing.
Regarding the interoperation of DiffServ and BBs with RSVP, [RFC 2638] assumes that the boundary router of a DS domain might intercept RSVP messages and redirect them to the BB for admission control. Unfortunately, this would require changing the behavior of the boundary router, which is normally not achievable with of-the-shelf equipment. Instead, the invention uses direct RSVP Shadowing communication between a host and the QoS Managers, and potentially between adjacent QoS Managers.
[RFC 2998] describes a QoS architecture using IntServ/RSVP at its edges and DiffServ in its core, with the scope of IntServ/RSVP and DiffServ areas being largely variable. In one extreme case, the IntServ areas might only consist of the source and destination hosts of a data flow using reservation. The invention falls into this category, as it can use a specialized RSVP Shadowing implementation in the hosts (and, of course, in the QoS Managers) only, not in any legacy RSVP router. Therefore, it will typically disable RSVP processing in legacy routers inside of the DS domains, to facilitate consistent resource management by a QoS Manger. A difference of the invention to [RFC 2998] is that, at least in some embodiments, the invention also considers a sequence of DS domains interconnected by IntServ/RSVP sections, instead of the one coherent DiffServ area.
[RFC 2998] optionally allows for DSCP marking and pre-conditioning performed by trusted hosts on behalf of a DS region. As the sending host is the last network element capable of performing these actions in the invention's architecture, this behavior must be used by the invention. Furthermore, the operation of RSVP across a DS region requires that its DS areas export characterization parameters for update of the Advertising Specification (Adspec) carried by RSVP, which is also described in [RFC 2998]. The invention must naturally adhere to this requirement, too.
Concerning the management of a DS area by means of a BB, [RFC 2998] states that the border router of the DS area should participate in the RSVP signaling and communicate with the BB for admission control of a requested data flow. Like the approach assumed by [RFC 2638], this would typically require changing of the behavior of of-the-shelf equipment and hence not be feasible.
[RFC 3175] uses the DSCP of packets for classification within an RSVP aggregation region, with the DSCP chosen by a downstream, deaggregating router, as it first has available all information to select an appropriate DSCP, which is reported upstream by means an RSVP DCLASS object. In some embodiments, the invention similarly uses DSCP selection in a downstream domain and reporting to an upstream domain, to enable dynamic upstream DSCP re-marking.
[RFC 2814] uses a specialized SBM-compliant RSVP stack implementation, which redirects RSVP messages to the designated SBM (DSBM) responsible for an outbound link. The DSBM in turn forwards the message towards its destination, effectively inserting itself into the RSVP path. Whereas the RSVP Shadowing stack in a host using the invention similarly first contacts the local QoS Manager instead of forwarding RSVP messages towards the real destination, it uses specialized RSVP Shadowing messages for this purpose, instead of redirected “original” messages. Even in some embodiments of the invention in which RSVP Shadowing messages are processed hop by hop between QoS Managers, that chain of QoS Manager communication is built up for the RSVP Shadowing communication only, not for “original” E2E messages.
Within the network(s) of a company, deployment of QoS based on pure IntServ/RSVP requires a significantly high granularity of RSVP-capable routers, which is a costly approach. Alternatively, a lower granularity of RSVP routers in combination with SBM-compliant switches may be chosen, which is less costly, but still far more expensive than using DiffServ-capable switches and routers only. Unfortunately, quantifiable application-centric QoS requires some kind of resource request/negotiation protocol, a feature not standardized for a pure DiffServ approach. The current approaches for interoperation of IntServ/RSVP with DiffServ intended to fill this gap either require modification of network equipment, which may not be feasible with off-the-shelf equipment, or support of those extensions by current equipment, which is not widespread and would also increase the costs of the solution.